Pull request overview

This PR fixes delayed cancellation observation when AndroidMessageHandler is blocked reading the response body (after headers are received). It does so by wrapping the response stream to actively disconnect/close the underlying HttpURLConnection when the read cancellation token is canceled, and adds regression coverage for both ResponseContentRead and ResponseHeadersRead scenarios (body read canceled after headers).

Changes:

• Add a cancellation-aware response body stream wrapper that aborts stalled reads by calling HttpURLConnection.Disconnect() and disposing the response stream when cancellation is requested.
• Wire the wrapped stream into AndroidMessageHandler response content creation.
• Add HttpListener-based device tests covering prompt body-read cancellation for both completion options.

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 1

⚠️ Needs Changes

Summary: This PR adds cancellation support for response body reads in AndroidMessageHandler by wrapping the response stream in a CancellationAwareResponseStream that disconnects the HttpURLConnection when a CancellationToken is canceled. The approach is sound — registering a cancellation callback to force-close the connection is the right pattern for unblocking stalled Java I/O.

Issues found:

Key concern: The CancellationAwareResponseStream takes dispose ownership of httpConnection, but AndroidHttpResponseMessage also disposes the same connection instance — creating double-dispose and unclear ownership. The AbortRead callback and Dispose method also race on stream.Dispose().

Positive callouts:

• Clean separation of the cancellation wrapper as a nested class
• Good use of CancellationToken.Register + exception filter pattern
• The ShouldMapToCancellation exception mapping covers the right exception types from the Java interop layer
• Well-structured test server with proper synchronization via TaskCompletionSource
• Tests cover both ResponseContentRead and ResponseHeadersRead completion options

Generated by Android PR Reviewer for issue #11554 · ● 14.1M

✅ LGTM — Clean, well-designed fix

Summary: The PR wraps the response stream in a CancellationAwareResponseStream that registers a cancellation callback to disconnect the HttpURLConnection and dispose the stream, unblocking stalled reads. The approach is sound — it correctly handles the ReadAsync/CopyToAsync paths that StreamContent actually uses, maps the resulting exceptions to OperationCanceledException, and uses Interlocked for thread-safe double-dispose protection.

Positive callouts:

• The QueueAbortRead → Task.Run(AbortRead) pattern avoids blocking the cancellation callback thread — good attention to detail
• TaskCreationOptions.RunContinuationsAsynchronously on the TaskCompletionSource prevents deadlocks in the test server
• The test infrastructure (StalledResponseServer) is well-structured with proper cleanup in TearDown
• Good coverage of both ResponseContentRead and ResponseHeadersRead completion options

CI: dotnet-android ✅ passed. Xamarin.Android-PR not yet visible (expected for a recently pushed direct PR).

Issues: 0 ❌ · 0 ⚠️ · 3 💡

Generated by Android PR Reviewer for issue #11554 · ● 12.5M

⚠️ Needs Changes

Nice fix for response body cancellation — the CancellationAwareResponseStream approach with Disconnect() + stream disposal is a clean way to unblock stalled reads. The test design with a stalled HTTP server is well thought out.

Issues found

❌ Missing field declaration — stalledResponseServer is used but never declared in the test class. This will fail to compile.

💡 Per-read CancellationToken.Register — The registration/disposal happens on every ReadAsync call in a tight loop. Consider registering once and disposing in Dispose.

💡 Test coverage — Consider a positive test (non-canceled read completes normally) to verify the wrapper doesn't break the happy path.

CI Status

• ✅ dotnet-android — succeeded
• ✅ license/cla — succeeded
• ⏳ Xamarin.Android-PR — not yet reported (will likely surface the compile error above)

Generated by Android PR Reviewer for issue #11554 · ● 17.4M

New tests look green: